I'm currently developing an nRF51822-based embedded device. Being one the Qt/Qt Creator maintainers in Debian I would of course try to use it for the development. Turns out it works pretty good... with some caveats.

There are already two quite interesting blog posts about using Qt Creator on MAC and on Windows, so I will not repeat the basics, as they are there. Both use qbs, but I managed to use CMake.

Instead I'll add some tips on the stuff that I needed to solve in order to make this happen on current Debian Sid.

• The required toolchain is already in Debian, just install binutils-arm-none-eabi, gcc-arm-none-eabi and gdb-arm-none-eabi.
• You will not find arm-none-eabi-gdb-py on the gdb-arm-none-eabi package. Fear not, the provided gdb binary is compiled against python so it will work.
• To enable proper debugging be sure to follow this flag setup. If you are using CMake like in this example be sure to modify CMake/toolchain_gcc.cmake as necessary.
• In Qt Creator you might find that, while try to run or debug your app, you are greated with a message box that says "Cannot debug: Local executable is not set." Just go to Projects Run and change "Run configuration" until you get a valid path (ie, a path to the .elf or .out file) in the "Executable" field.

As was posted a couple of weeks ago, the latest version of KDEPIM has been uploaded to unstable.

All packages are now uploaded and built and we believe this version is ready to be more broadly tested.

If you run unstable but have refrained from installing the kdepim packages up to now, we would appreciate it if you go ahead and install them now, reporting any issues that you may find.

Given that this is a big update that includes quite a number of plugins and libraries, it's strongly recommended that you restart your KDE session after updating the packages.

Happy hacking,

The Debian Qt/KDE Team.

Note lun jul 18 08:58:53 ART 2016: Link fixed and s/KDE/KDEPIM/.

For those who care about kdepim (kmail, kontact, korganizer, etc)

Currently the latest version of kdepim is available in experimental. According to our limited tests it's working way better than kdepim 4.14 (more stable, more performant, less bugs). However migrating from one to the other is not a trivial process (distribution wise, hopefully not for our users).

Among the drawbacks in the new kdepim: knode, ktimetracker and kjots were dropped from the official kdepim components. kjots is now an independent project, not tied to the kdepim release cycle. But more importantly, knode and ktimetracker are not maintained upstream any more, we are temporarily still shipping the old KDE 4 versions, but we will drop them after stretch unless they get new upstream maintainers.

To iron out the wrinkles that are surely still there, we are now planning to start a transition for kdepim, effectively blocking all kdepim related packages in unstable until the transition is complete. This will allow us to keep the current kdepim in testing unchanged until kdepim 16.04 is ready to migrate fully to testing.

If you want to test the new kdepim versions right now, please use the version in experimental, as uploading all the packages to unstable will take some time until there is a working kdepim in unstable (mixing experimental and the unstable uploads should be fine).

If you depend on having a working kdepim, please avoid installing the new kdepim packages that will be landing in unstable in the following days, until all the components are available. We expect this will take a couple of weeks, we will post another entry when the packages are ready in unstable.

A list of the binary packages involved in the transition can be found [here].

If you find issues in the new packages, please let us know either via irc in #debian-kde, the kde mailing list debian-kde@lists.debian.org, or send us a bug report (please make sure that it wasn't reported before).

We'll send an updated note when kdepim is fully uploaded to unstable.

Happy hacking,

It has been an exciting first week of my internship. I was able to produce a few patches,
and submitted upstream, as well as into debian packaging. I am hopeful they will get accepted,
preferably upstream so all can benefit! kapptemplate:
https://bugs.kde.org/show_bug.cgi?id=363448
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825122 choqok:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825322 However, after speaking with Lisandro ( choqok maintainer ) I decided a better course of action
is to try and fix the actual source of the problem, kconfig_compiler from kde4libs is generating
non utf-8 cpp and header files under certain conditions like an environment that does not have a
locale set. Of course, I have some help with this from wonderful folks in KDE, which is good
because kde4libs codebase is HUGE! So I hope to have two new bugs early next week for choqok. I checked up on my existing kdevplatform bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815962 And noticed it has not received attention, so I created upstream bug:
https://bugs.kde.org/show_bug.cgi?id=363615 And updated the debian bug patch DEP 3 with upstream bug url. I have been working on kdevelop-php without success yet, looks like build-id
( I still need to find the source ) and embedded kernel which I think I found,
though I will reach out to my awesome mentor to get some help on this one. I did not knock out quite as many builds as I wanted, but I picked some hard ones
that are new to me So in the end it was a very successful first week, because I
have learned several new things that will help me with future reproducible builds. Have a great weekend.

So far the only missing submodule in Debian's Qt5 stack is QtWebEngine. None of us the current Qt maintainers have the time/will to do the necessary stuff to have it properly packaged.

So if you would like to have QtWebEngine in Debian and:

• You have C++ libraries' packaging skills.
• You have a powerful enough machine/enough patience to do the necessary builds (8+ GB RAM+swap required).
• You are willing to deal with 3rd party embedded software.
• You are willing to keep up with security fixes.
• You are accessible through IRC and have the necessary communications skills to work together with the rest of the team.

What happened in the reproducible builds effort between February 7th and February 13th 2016:

Toolchain fixes

• James McCoy uploaded devscripts/2.16.1 which makes dcmd supports .buildinfo files. Original patch by josch.
• Lisandro Dami n Nicanor P rez Meyer uploaded qt4-x11/4:4.8.7+dfsg-6 which make files created by qch reproducible by using a fixed date instead of the current time. Original patch by Dhole.

Norbert Preining rejected the patch submitted by Reiner Herrmann to make the CreationDate not appear in comments of DVI / PS files produced by TeX. He also mentioned that some timestamps can be replaced by using the -output-comment option and that the next version of pdftex will have patches inspired by reproducible build to mitigate the effects (see SOURCE_DATE_EPOCH patches) .

Packages fixed The following packages have become reproducible due to changes in their build dependencies: abntex, apt-dpkg-ref, arduino, c++-annotations, cfi, chaksem, clif, cppreference-doc, dejagnu, derivations, ecasound, fdutils, gnash, gnu-standards, gnuift, gsequencer, gss, gstreamer0.10, gstreamer1.0, harden-doc, haskell98-report, iproute2, java-policy, libbluray, libmodbus, lizardfs, mclibs, moon-buggy, nurpawiki, php-sasl, shishi, stealth, xmltex, xsom. The following packages became reproducible after getting fixed:

• adblock-plus/2.7.1+dfsg-1 uploaded by David Pr vot, original patch by Dhole.
• gyoto/1.0.2-2 uploaded by Thibaut Paumard, original patch by Chris Lamb.
• libosmocore/0.9.0-4 by Ruben Undheim.
• libsyncml/0.5.4-2.3 uploaded by Mattia Rizzolo, original patch by akira.
• ltsp/5.5.6-2 by Vagrant Cascadian.
• mira/4.9.5-5 by Michael R. Crusoe.
• pagekite/0.5.8a-1 uploaded by Petter Reinholdtsen, original patch by Chris Lamb.
• plexus-containers/1.0~beta3.0.7-8 by Emmanuel Bourg.
• propellor/2.15.4-1 by Sean Whitton.
• salmon/0.4.2+ds1-2 uploaded by Michael R. Crusoe, original patch by Chris Lamb.
• wmii-doc/1:1-15 by Reiner Herrmann.

Some uploads fixed some reproducibility issues, but not all of them:

• dipy/0.10.1-1 uploaded by Yaroslav Halchenko, original patch by Juna Picca.
• suomi-malaga/2.0-1 uploaded by Timo Jyrinki, original patch by Chris Lamb.
• west-chamber/20100405+svn20111107.r124-7 by Ying-Chun Liu, original patch by Chris Lamb.

Patches submitted which have not made their way to the archive yet:

• #813944 on cvm by Reiner Herrmann: remove gzip headers, fix permissions of some directories and the order of the md5sums.
• #814019 on latexdiff by Reiner Herrmann: remove the current build date from documentation.
• #814214 on rocksdb by Chris Lamb: add support for SOURCE_DATE_EPOCH.

reproducible.debian.net A new armhf build node has been added (thanks to Vagrant Cascadian) and integrated into the Jenkins setup for 4 new armhf builder jobs. (h01ger) All packages for Debian testing (Stretch) have been tested on armhf in just 42 days. It took 114 days to get the same point for unstable back when the armhf test infrastructure was much smaller. Package sets have been enabled for testing on armhf. (h01ger) Packages producing architecture-independent ( Arch:all ) binary packages together with architecture dependent packages targeted for specific architectures will now only be tested on matching architectures. (Steven Chamberlain, h01ger) As the Jenkins setup is now made of 252 different jobs, the overview has been split into 11 different smalller views. (h01ger)

Package reviews 222 reviews have been removed, 110 added and 50 updated in the previous week. 35 FTBFS reports were made by Chris Lamb, Danny Edel, and Niko Tyni.

Misc. The recordings of Ludovic Court s' talk at FOSDEM 16 about reproducible builds and GNU Guix is now available. One can also have a look at slides from Fabian Keil's talk about ElecrtroBSD and Baptiste Daroussin's talk about FreeBSD packages.

What happened in the reproducible builds effort this week: Media coverage Nathan Willis covered our DebConf15 status update in Linux Weekly News. Access to non-LWN subscribers will be given on Thursday 24th. Linux Journal published a more general piece last Tuesday. Unexpected praise for reproducible builds appeared this week in the form of several iOS applications identified as including spyware. The malware was undetected by Apple screening. This actually happened because application developers had simply downloaded a trojaned version of XCode through an unofficial source. While reproducible builds can't really help users of non-free software, this is exactly the kind of attacks that we are trying to prevent in our systems. Toolchain fixes

• Mathieu Malaterre uploaded abi-compliance-checker/1.99.11-1 which drops the timestamps from the generated HTML reports and makes the generated .abi.tar.gz files reproducible. Original patches by Chris Lamb.

Niko Tyni wrote and uploaded a better patch for the source order problem in libmodule-build-perl. Tristan Seligmann identified how the code generated by python-cffi could be emitted in random order in some cases. Upstream has already fixed the problem. Packages fixed The following 24 packages became reproducible due to changes in their build dependencies: apache-curator, checkbox-ng, gant, gnome-clocks, hawtjni, jackrabbit, jersey1, libjsr305-java, mathjax-docs, mlpy, moap, octave-geometry, paste, pdf.js, pyinotify, pytango, python-asyncssh, python-mock, python-openid, python-repoze.who, shadow, swift, tcpwatch-httpproxy, transfig. The following packages became reproducible after getting fixed:

• apparmor/2.10-2 uploaded by intrigeri, fixed upstream by Christian Boltz, with the same change suggested by Reiner Herrmann.
• ardour/1:4.2~dfsg-2 by IOhannes m zm lnig.
• dcmtk/3.6.1~20150629-1 uploaded by Andreas Tille, original patch by akira.
• deap/1.0.1-4 by Daniel Stender.
• firebird2.5/2.5.4.26856.ds4-2 by Damyan Ivanov.
• gamera/3.4.2+svn1437-1 by Daniel Stender.
• genometools/1.5.7-1 by Sascha Steinbiss.
• golang-github-go-xorm-core/0.4.4-1 by Alexandre Viau.
• klibc/2.0.4-4 by Ben Hutchings.
• libgtk2-perl/2:1.2496-3 by intrigeri.
• lsof/4.89+dfsg-0.1 uploaded by Laurent Bigonville, original patch by Lunar.
• monotone/1.1-6 by Markus Wanner.
• ndisc6/1.0.1-4 by Santiago Vila.
• privoxy/3.0.23-4 by Roland Rosenfeld.
• ruby-flexmock/2.0.0~rc1-1 by Antonio Terceiro.
• ruby-html2haml/2.0.0-1 by Lunar.
• tunnelx/20140102-3 uploaded by Wookey, original patch by Chris Lamb.
• wtforms/2.0.2-1 by Orestis Ioannou, original patch by Juan Picca.

Some uploads fixed some reproducibility issues but not all of them:

• maxima/5.37-1 by Camm Maguire, report by akira.

Patches submitted which have not made their way to the archive yet:

• #783152 on kmod by Lunar: export SOURCE_DATE_EPOCH in debian/rules.
• #799010 on 389-ds-base by Chris Lamb: use SOURCE_DATE_EPOCH value as the build date.
• #799206 on python-sqlalchemy-utils by Chris Lamb: sort the list of extra requirement.
• #799330 on cappuccino by Chris Lamb: pass a fixed seed to polygen.
• #799410 on segment by Chris Lamb: use date of the latest debian/changelog entry as build date.

reproducible.debian.net Tests for Coreboot, OpenWrt, NetBSD, and FreeBSD now runs weekly (instead of monthly). diffoscope development Python 3 offers new features (namely yield from and concurrent.futures) that could help implement parallel processing. The clear separation of bytes and unicode strings is also likely to reduce encoding related issues. Mattia Rizolo thus kicked the effort of porting diffoscope to Python 3. tlsh was the only dependency missing a Python 3 module. This got quickly fixed by a new upload. The rest of the code has been moved to the point where only incompatibilities between Python 2.7 and Pyhon 3.4 had to be changed. The commit stream still require some cleanups but all tests are now passing under Python 3. Documentation update The documentation on how to assemble the weekly reports has been updated. (Lunar) The example on how to use SOURCE_DATE_EPOCH with CMake has been improved. (Ben Beockel, Daniel Kahn Gillmor) The solution for timestamps in man pages generated by Sphinx now uses SOURCE_DATE_EPOCH. (Mattia Rizzolo) Package reviews 45 reviews have been removed, 141 added and 62 updated this week. 67 new FTBFS reports have been filled by Chris Lamb, Niko Tyni, and Lisandro Dami n Nicanor P rez Meyer. New issues added this week: randomness_in_r_rdb_rds_databases, python-ply_compiled_parse_tables. Misc. The prebuilder script is now properly testing umask variations again. Santiago Villa started a discussion on debian-devel on how binNMUs would work for reproducible builds.

Todays Debian Jessie's update brings a fix in Akonadi that you certainly want in your system.

There was a bug in Akonadi that made it leak files. And if you use Kmail you will certainly want to keep reading: most of us who tested it before pushing it to testing (and now to stable) removed more than 4 GiB of useless data from our homes.

The bug that makes Akonadi leak files gets solved with the latest stable update (and has been in testing for a couple of months already). But you need to purge the leaked files. It's pretty easy: with your normal user account just run:

akonadictl fsck

That's all. After a while you will get back a lot of disk space. Note that you don't need the Akonadi fix in order to run this tool and recover your space. The fix just makes sure this won't happen again.

A few days ago, fellow Qt/KDE team member Lisandro gave an update on the situation with migration to Plasma 5 in Debian Testing (AKA Stretch). It s changed again. All of Plasma 5 is now in Testing. The upgrade probably won t be entirely smooth, which we ll work on that after the gcc5 transition is done, but it will be much better than the half KDE4 SC half Kf5/Plasma 5 situation we ve had for the last several days. The issues with starting kwin should be resolved once users upgrade to Plasma 5. To use the current kwin with KDE SC 4, you will need to add a symlink from /usr/bin/kwin to /usr/bin/kwin_x11. That will be included in the next upload after gcc5. Systemsettings and plasma-nm now work. In my initial testing, I didn t see anything major that was broken. One user reported an issue with sddm starting automatically, but it worked fine for me. During the upgrade you should get a debconf prompt asking if you want to use kdm or sddm. Pick sddm. When I tried to dist-upgrade, apt wanted to remove task-kde-desktop. I let it remove it and some other packages and then in a second step did apt-get install task-kde-desktop. That pulled it back in successfully along with adding and removing a reasonably large stack of packages. Obviously we need to make that work better before Stretch is released, but as long as you don t restart KDE in between those two steps it should be fine. Lastely, I used apt-get autoremove to clear out a lot of no longer needed KDE4 things (when it asks if you want to stop the running kdm, say no). Here are a few notes on terminology and what I understand of the future plans: What used to be called KDE is now three different things (in part because KDE is now the community of people, not the software): KDE Frameworks 5 (Kf5): This is a group of several dozen small libraries that as a group, roughly equate to what used to be kdelibs. Plasma (Workspaces) 5: This is the desktop that we ve just transitioned to. Applications: These are a mix of kdelibs and Kf5 based applications. Currently in Testing there are some of both and this will evolve over time based on upstream development. As an example, the Kf5 based version of konsole is in Unstable and should transition to Testing shortly. Finally, thanks to Maximiliano Curia (maxy on IRC) for doing virtually all of the packaging of Kf5, Plasma 5, and applications. He did the heavy lifting, the rest of us just nibbled around the edges to keep it moving towards testing.

Dear Debian/KDE users,

We are aware that the current situation in testing is very unfortunate, with two main issues:

1. systemsettings transitioned to testing before the corresponding KDE Control Modules. The result is that systemsettings displays an empty screen. This is tracked in the following bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790703.
2. plasmoids such as plasma-nm transitioned to testing before plasma-desktop 5. The result is that the plasmoid are no longer displayed in the system tray.

We are working on getting plasma-desktop to transition to testing as soon as possible (hopefully in 2 days time), which will resolve both those issues. We appreciate that the transition to KF5 is much rougher than we would have liked, and apologize to all those impacted.

On behalf of the Qt/KDE team,
Lisandro.

Qt 4.8.7 has been released today. Quoting from the blog post (emphasis is mine):

Many users have already moved their active projects to Qt 5 and we encourage also others to do so. With a high degree of source compatibility, we have ensured that switching to Qt 5 is smooth and straightforward. It should be noted that Qt 4.8.7 provides only the basic functionality to run Qt based applications on Mac OS X 10.10, full support is in Qt 5.

Qt 4.8.7 is planned to be the last patch release of the Qt 4 series. Standard support is available until December 2015, after which extended support will be available. We recommend all active projects to migrate to Qt 5, as new operating systems and compilers with Qt 4.8 will not be supported. If you have challenges migrating to Qt 5, please contact us or some of our service partners for assistance

Have you started to port your project?

Hi everyone! As you might know Qt4 has been deprecated (in the sense "you better start to port your code") since Qt5's first release in December 19th 2012. Since that point on Qt4 received only bugfixes. Upstream is about to release the last point release, 4.8.7. This means that only severe bugs like security ones will get a chance to get solved.

Moreover upstream recommended keeping Qt4 until 2017. If we get a Debian release every 2 years that will make Jessie oldstable in 2017 and deprecated in 2018. This means we should really consider starting to port code using Qt4 to Qt5 during Stretch's developing life cycle.

It is important to note that Qt4 depends on a number of dependencies that their maintainers might want to get removed from the archive for similar reasons. In this case we will simply don't hesitate in removing their support as long as Qt4 keeps building. This normally doesn't mean API/ABI breakage but missing plugins that will diminish functionality from your apps, maybe even key ones. As an example let's take the **hypothetical** case in which the libasound2 maintainers are switching to a new libasound3 which is not API-compatible and removing libasound2 in the process. In this case we will have no choice but to remove the dependency and drop the functionality it provides. This is another of the important reasons why you should be switching to Qt5.

Qt4's webkit removalWebkit is definitely not an easy piece of code to maintain. For starters it means having a full copy of the code in the archive for both Qt4 and Qt5. Now add to that the fact that the code evolves quickly and thus having upstream support even for security bugs will be getting harder and harder. So we decided to remove Qt4's webkit from the archive. Of course we still have a lot of KDE stuff using Qt4's webkit, so it won't disappear "soon", but it will at some point.

PortingSome of us where involved in various Qt4 to Qt5 migrations [0] and we know for sure that porting stuff from Qt4 to Qt5 is much much easier and less painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4. In order to ease the transition time we have provided Wheezy backports for Qt5.

Don't forget to take a look at the C++ API changes page [1] whenever you start porting your application.

[0] http://pkg-kde.alioth.debian.org/packagingqtstuff.html
[1] http://doc.qt.io/qt-5/sourcebreaks.html

Temporarily shipping both Qt4 and Qt5 builds of your libraryIn case you maintain a library chances are that upstream already provides a way to build it using Qt5. Please note there is no point in shipping an application built with both flavours, please use Qt5 whenever possible. This double compilation should be left only for libraries.

You can't mix Qt4 and Qt5 in the same binary, but you may provide libraries compiled against one or the other. For example, your source package foo could provide both libqt4foo1 and libqt5foo1. You need to mangle your debian/rules and/or build system accordingly to achieve this.

A good example both for upstream code allowing both styles of compilation and debian packaging is phonon. Take a look at the CMakeLists.txt files for seeing how a source can be built against both flavours and another to debian/rules to see an example of how to handle the compilation. Just bear in mind that you
need to replace $(overridden_command) with the command itself, that variable substitution comes from internal stuff from our team and you should not be using it without a very good reason. If in doubt, feel free to ask us on IRC [2] or on the mailing list [3].

[2] irc.debian.org #debian-kde
[3] debian-kde@lists.debian.org

TimelineWe plan to start filing wishlist bugs soon. Once we get most of KDE stuff running with Qt5's webkit we will start raising the severities.

We the Debian Qt/KDE Team want to early-announce [maintainer warning] our decision to remove Qt4 from Jessie+1. This warning is mostly targeted at upstreams.

Qt4 has been deprecated since Qt5's first release on December 19th 2012, that means almost two years ago!

So far we had bugfixes-only releases, but upstream has announced that they will end this support on august 2015. This already means we will have to do a special effort from that point on for Jessie in case RC bugs appears, so having it in Jessie+1 is simply a non-go.

Some of us where involved in various Qt4 to Qt5 migrations [0] and we know for sure that porting stuff from Qt4 to Qt5 is much much easier and less painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4. In order to easy the transition time we have provided Wheezy backports for Qt5.

Don't forget to take a look at the C++ API change page [1] whenever you start porting your application.

[0] http://perezmeyer.blogspot.com.ar/2014/03/porting-qt-4-apps-to-qt-5-example-with.html
[1] http://qt-project.org/doc/qt-5.0/qtdoc/sourcebreaks.html

[maintainer warning] **Remember the freeze** and do not upload packages ported to Qt5 to unstable. The best thing you can do now is to ask your upstream if the code can be compiled against Qt5 and, why not, try it yourself.

Our first priority now is to release Jessie, and this is why this is an early announce.

In more or less 24 hs a few days most of Qt 5.3.2 will be available as a Wheezy backport. That means that if you are using Debian stable you don't need to wait for Jessie: just wait a few hours, add wheezy-backports's repo to your sources.list and get it :)

The rest of Qt 5 will arrive soon.

This is the same version that will be shipped in Jessie, so whatever you develop with it will work with the next Debian stable release :)

Don't forget: you better start porting your Qt4 apps to Qt5!

Note 2014-10-10: uups, it will still take a few days, but it will be there soon :)

Note 2014-10-15: currently building!

Qt 5.3.2 has entered testing a few hours ago. This will be the version of Qt we will release with Debian Jessie, and it happens to be a nice coincidence, because upstream focused in stability for the 5.3 branch.

I'll now focus in fixing as many bugs as possible and in backporting Qt5 to Wheezy.

Let me warn you: if you are an upstream for a Qt4 based project be sure to be ready to switch to Qt5. If you are a maintainer of a Qt4 based project you better start asking your upstream to be ready for it :)

Wheezy for industrial software development I'm helping with setting up a wheezy-based toolchain for industrial automation. The basic requirements are: live-build, C++11, Qt 5.3, and a frozen internal wheezy mirror. debmirror A good part of a day's work was lost because of #749734 and possibly #628779. Mirror rebuild is still ongoing, and fingers crossed. This is Italy, and you can't simply download 21Gb of debs just to see how it goes. C++11 Stable toolchains for C++11 now exist and have gained fast adoption. It makes sense, since given what is in C++11 it is unthinkable to start a new C++ project with the old standard nowadays. C++11 is supported by g++ 4.8+ or clang 3.3+. None of them is available on wheezy or wheezy-backports. Backports exist of g++ 4.8 only for Ubuntu 12.04, but they are uninstallable on wheezy due at least to a different libc6. I tried rebuilding g++4.8 on wheezy but quickly gave up. clang 3.3 has a build dependency on g++ 4.8. LOL. However, LLVM provides an APT repository with their most recent compiler, and it works, too. C++11 problem solved! Qt 5.3 Qt 5.3 is needed because of the range of platforms it can target. There is no wheezy backport that I can find. I cannot simply get it from Qt's Download page and install it, since we need it packaged, to build live ISOs with it. I'm attempting to backport the packages from experimental to wheezy. Here are its build dependencies: libxcb-1.10 (needed by qt5) Building this is reasonably straightforward. libxkbcommon 0.4.0 (needed by qt5) The version from jessie builds fine on wheezy, provided you remove --fail-missing from the dh_install invocation. libicu 52.1 (needed by harfbuzz) The jessie packages build on wheezy, provided that mentions of clang are deleted from source/configure.ac, since it fails to build with clang 3.5 (the one currently available for wheezy on llvm.org). libharfbuzz-dev Backporting this is a bloodbath: the Debian packages from jessie depend on a forest of gobject hipsterisms of doom, all unavailable on wheezy. I gave up. qt 5.3 qtbase-opensource-src-5.3.0+dfsg can be made to build with an embedded version of harfbuzz, with just this change:

diff -Naur a/debian/control a/debian/control
--- a/debian/control    2014-05-20 18:48:27.000000000 +0200
+++ b/debian/control    2014-05-29 17:45:31.037215786 +0200
@@ -28,7 +28,6 @@
                libgstreamer-plugins-base0.10-dev,
                libgstreamer0.10-dev,
                libgtk2.0-dev,
-               libharfbuzz-dev,
                libicu-dev,
                libjpeg-dev,
                libmysqlclient-dev,
diff -Naur a/debian/rules b/debian/rules
--- a/debian/rules  2014-05-18 01:56:37.000000000 +0200
+++ b/debian/rules  2014-05-29 17:45:25.738634371 +0200
@@ -108,7 +108,6 @@
                -plugin-sql-tds \
                -system-sqlite \
                -platform $(platform_arg) \
-               -system-harfbuzz \
                -system-zlib \
                -system-libpng \
                -system-libjpeg \

(thanks Lisandro Dami n Nicanor P rez Meyer for helping me there!) There are probably going to be further steps in the Qt5 toolchain. Actually, let's try prebuilt binaries The next day with a fresh mind we realised that it is preferable to reduce our tampering with the original wheezy to a minimum. Our current plan is to use wheezy's original Qt and Qt-using packages, and use Qt's prebuilt binaries in /opt for all our custom software. We run Qt's installer, tarred the result, and wrapped it in a Debian package like this:

$ cat debian/rules
#!/usr/bin/make -f
QT_VERSION = 5.3
%:
    dh $@
override_dh_auto_build:
    dh_auto_build
    sed -re 's/@QT_VERSION@/$(QT_VERSION)/g' debian-rules.inc.in > debian-rules.inc
override_dh_auto_install:
    dh_auto_install
    # Download and untar the prebuild Qt5 binaries
    install -d -o root -g root -m 0755 debian/our-qt5-sdk/opt/Qt
    curl http://localserver/Qt$(QT_VERSION).tar.xz   xz -d   tar -C debian/our-qt5-sdk/opt -xf -
    # Move the runtime part to our-qt5
    install -d -o root -g root -m 0755 debian/our-qt5/opt/Qt
    mv debian/our-qt5-sdk/opt/Qt/$(QT_VERSION) debian/our-qt5/opt/Qt/
    # Makes dpkg-shlibdeps work on packages built with Qt from /opt
    # Hack. Don't try this at home. Don't ever do this unless you
    # know what you are doing. This voids your warranty. If you
    # know what you are doing, you won't do this.
    find debian/our-qt5/opt/Qt/$(QT_VERSION)/gcc_64/lib -maxdepth 1 -type f -name "lib*.so*" \
          sed -re 's,^.+/(lib[^.]+)\.so.+$$,\1 5 our-qt5 (>= $(QT_VERSION)),' > debian/our-qt5.shlibs
$ cat debian-rules.inc.in
export PATH := /opt/Qt/@QT_VERSION@/gcc_64/bin:$(PATH)
export QMAKESPEC=/opt/Qt/@QT_VERSION@/gcc_64/mkspecs/linux-clang/

To build one of our packages using Qt5.3 and clang, we just add this to its debian/rules:

include /usr/share/our-qt5/debian-rules.inc

Wrap up We got the dependencies sorted. Hopefully the mirror will rebuild itself tonight and tomorrow we can resume working on our custom live system.

There is a strange bug in Planet Debian I am seeing since I joined. It is rather minor, but since it is an accessibility bug, I'd like to mention it here. I have written to the Planet Debian maintainers, and was told to figure it out myself. This is a pattern, accessibility is considered wishlist, apparently. And the affected people are supposed to fix it on their own. It is better if I don't say anything more about that attitude.

As a followup for my previous blog post, I decided to port QAntenna to Qt 5. Here's my experience.

First of all, I ran Qt 5's qmake:

qmake -qt5

Then I just ran make:

make

The first error that appeared was that QFileDialog does not has a setFilters() method. I couldn't find this on on the C++ API change page but looking at the class' documentation I found it was renamed to setSectionsMovable(). Fine, let's just change that and continue compiling.

The next errors came all from the same class QHeaderView. This time the changes are documented in the above linked page, so it was a matter to replace setMovable() with setSectionsMovable() and setResizeMode() with setSectionResizeMode(). Fixed, let's continue.

The following error turned out to be the last one: toAscii() has been deprecated in favor of toLatin1(). Once this was fixed voil , QAntenna is running with Qt 5.

Easy, wasn't it?

I have just pushed the new version to Debian unstable.

As you might know, Qt 4 is now in bug-fixes-only maintenance mode. This means that only bug fixes are allowed to be pushed to Qt 4's repository, but no new features.

On the other hand, Qt 5 is already here. Porting existing apps from Qt 4 to Qt 5 is actually easier than it was to port Qt 3 stuff to Qt 4. Take a look at this Qt project's wiki page for more info. Also pay attention at the links at the bottom of it under "Recommended Reading".

Some time ago I blogged about the 5.2.0 status in Debian experimental. We currently have it in testing with a much better status:


And we also have 5.2.1 in experimental with an even better status:

Note: qttools is FTBFS in armhf just because of some symbols changes, it will be fixed on the next upload.

Don't be afraid of getting it from experimental! Take a look at this blog post to know how to compile with Qt 5 in Debian.

BonusI have also uploaded Qt Creator built against Qt 5 to experimental. I plan to push it to unstable with Qt 5.2.1.